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Status of Claims 

1 . This non-final office action is in reply to the Amendments and Request for Continued Examination 
filed on 24 July 2009. 

2. Claims 1, 14, 15, 22, 28, 31, 32 and 34 have been amended. 

3. Claim 18 has previously been canceled. 

4. Claims 1-17 and 19-34 are currently pending and have been examined. 

Continued Examination Under 37 CFR 1.114 

5. A request for continued examination under 37 CFR §1.1 14, including the fee set forth in 37 CFR 
§1. 17(e), was filed in this application after final rejection. Since this application is eligible for 
continued examination under 37 CFR §1.114, and the fee set forth in 37 CFR 1.17(e) has been 
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 
§1.114. Examiner further notes that the instant application was revived following an 
abandonment by way of a Petition approved 14 September 2009. Consequently, Applicant's 
submission filed 24 July 2009 has been entered. 

Response to Amendments 

6. The objection to claim 34 is withdrawn in light of Applicant's amendments. 

7. The rejection of claim 14 under 35 USC §112, 2 nd paragraph is maintained for the reasons set 
forth below. 

8. The rejection of claim 34 under 35 USC §112, 2 nd paragraph is maintained for the reasons set 
forth below. 
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Response to Arguments 

9. Applicant's arguments received on 9 April 2009 have been fully considered but they are not 
persuasive. Referring to the previous Office action, Examiner has cited relevant portions of the 
references as a means to illustrate the systems as taught by the prior art. As a means of 
providing further clarification as to what is taught by the references used in the first Office action, 
Examiner has expanded the teachings for comprehensibility while maintaining the same grounds 
of rejection of the claims, except as noted above in the section labeled "Status of Claims." This 
information is intended to assist in illuminating the teachings of the references while providing 
evidence that establishes further support for the rejections of the claims. 

10. Applicant argues that the prior art of record, specifically Hanagan, does not teach "... or even 
mention that the customer billing system processes accounts with a set of dependent tasks. 
Hanagan fails to teach any solution to updating the system if there are any dependencies among 
the customer accounts." (Remarks, p.10). Examiner respectfully disagrees. Hanagan [0082], 
[0311] clearly mentions the aforementioned limitations: "The result is a workflow, identifying the 
proper order in which tasks must be completed , the estimated time required to perform a task, 
and the type of resource(s) required for each task." (emphasis added), and in [0329] describes 
" Task dependencies , service request dependencies, and resource availability are all taken into 
account during the scheduling process ." (emphasis added). 

11. Applicant also argues that the prior art, specifically Pather "does not disclose processing 
subscription accounts periodically. Additionally, Pather fails to make up for the deficiencies of 
Hanagan with respect to processing errored accounts a predetermined amount of times or by 
manual intervention." (Remarks, p. 11). Examiner, in the previous Office action indicated these 
teachings were present in Hanagan. Regarding the periodic processing aspects, Hanagan [0415] 
clearly teaches this, to wit: " Batch units of workload are initiated periodically , usually according to 
a pre-defined time schedule or by predictable arrival of an occasional event or file of events from 
an external system." (emphasis added). Moreover, Pather [1 1 ,43] refers to periodic processing of 
sorts, to wit: "The event provider that is providing these events is programmed to close the 
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current event batch periodically , which submits this batch of events for use in notification 
generation." (emphasis added). Finally, Pather [42,1] teaches "The <FailuresBeforeAbort> 
element might be used to define the number of retry attempts that are permissible before aborting 
any further attempts." (emphasis added) where the emphasized text corresponds to processing 
errored accounts a predetermined amount of times. Finally, Pather [48,5] refers to manual tasks: 
"Furthermore, if any subscription chronicle tables are being used to store subscription data, 
developers may want to define one or more rules that operate upon them as well. These queries 
can add, change, and delete subscription data in the chronicle tables, so that it is in the correct 
state for use by the application ." (emphasis added) where the emphasized text corresponds to 
the manual correction of errored accounts. 

12. In summary, the teachings of the prior art together teach every limitation of the rejected claims 
and/or demonstrate that the claimed invention is an obvious variation of what has been taught in 
the art. 

Claim Rejections - 35 USC §112 

13. The following is a quotation of the second paragraph of 35 U.S. C. §112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

14. Claims 14 and 34 are rejected under 35 U.S.C. §112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

• Claim 14: Examiner acknowledges that the previous issues pertaining to the have been 
largely addressed. Applicant however recites that "...to keep system resources under a ... 
threshold" is problematic in that it reads as if components (resources) must be under some 
threshold or number. Examiner believes, and for purposes of examination, Examiner 
interprets this as meaning that the utilization of system resources is kept under a 
predetermined threshold. Examiner requests either confirmation of this interpretation or 
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further clarification and/or amendment. Also, the phrase 'the number of dependencies' lacks 
sufficient antecedent basis. 
• Claim 34: Examiner acknowledges that the previous issues pertaining to the have been 
largely addressed. Applicant recites "wherein the bulk component processes the errored 
account with a predetermined threshold number of attempts to resolve the errored account 
until the account state is in par with the rest of accounts being processed by bulk mode." 
where it unclear and inconsistent that processing occurs "a predetermined threshold number 
of attempts to resolve..." and at the same time processing "until the account state is in par 
with the rest of accounts..." The inconsistency renders this claim vague and indefinite. 

• In addition, stating that processing continues until the account state "is in par" uses a 
relative if not vague term, hence is vague and indefinite based on the use of that phrase. 

• Finally, the claim recites "...is in par with the rest of accounts being processed" where the 
term "rest of accounts" lacks sufficient antecedent basis. Moreover, it is unclear as to 
whether this refers to 'eligible accounts' or 'errored account', hence is vague and 
indefinite. 

Claim Rejections - 35 USC §103 

15. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 

rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be 
patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to 
which said subject matter pertains. Patentability shall not be negatived by the manner in 
which the invention was made. 

16. Claims 1-17 and 19-33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hanagan, ef a/. (US PgPub 20040133487 A1) in view of Pather, et al. (US 7177859 B2). 
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Claims 1, 6, 7, 15, 22, 28 and 31: 

Hanagan describes and/or discloses a system (see title) and method (see e.g., [0004] "billing", 
"aggregates", and in [0082] "determine the tasks...") and computer-readable media with computer- 
executable instructions (claim 3 and [0452] "server programs") that facilitates task processing ([0082]) 
and periodic processing ([0306] "on a periodic basis") of subscription accounts ([0102] "customer 
subscription information") in the following limitations, as shown: 

• a bulk component ([0357] "batch environment") that concurrently processes ([0357] "automatically 
processed in parallel") a plurality of eligible accounts ([041 1] "row is valid" and in [0078] "providing 
advanced features to additionally support scripting and validations ." (emphasis added)) with a set 
of dependent tasks periodically (Hanagan [0329] "Task dependencies". Hanagan [0415] states 
" Batch units of workload are initiated periodically , usually according to a pre-defined time 
schedule or by predictable arrival of an occasional event or file of events from an external 
system." (emphasis added).); and 

• a removal component (Abstract: "The components are modular." and in [0252] "Filters can be set 
up to filter out records. [. . .] Filters are defined using the ERP graphical user interface ." (emphasis 
added) where 'filter out' corresponds to removal and 'ERP...' corresponds to component) that 
removes an account from the eligible accounts as an errored account if an error is associated 
therewith ([0250] "Single erroneous UE records are errored out and written to an Invalid Event 
Records File. If some records are rejected due to invalid field contents, the reason is written to an 
Error File." (emphasis added) where 'records' corresponds to eligible accounts and 'errored out' 
corresponds to an errored account). 

• an error component ([0149-56] "...in the case an error is detected." See also [0250] "The 
Validator") that that processes the errored account ([0250] "Single erroneous UE records are 
errored out and written to an Invalid Event Records File.") to resolve the error associated 
therewith (see [0250] and [0443] "Error Handling"), and merges the resolved errored account with 
bulk processing ([0250] "A GUI is also provided for error correction . [...] The validated UE records 
are written to files (different files (same format) for assembly and non-assembly records)." 
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(emphasis added) where 'validated' corresponds to resolved errored account and 'assembly' 
corresponds to merges... see also [0477] "The framework merges master and incremental 
update files...") of the eligible accounts by the bulk component when the resolved errored 
account is temporally aligned with the bulk processing ([0476] "Over time the master file will get 
out of synchronization with the database because of database inserts, updates or deletions that 
are applied to the database table. For large tables supporting time critical functionality, these 
additional changes are captured periodically and made available to running processes in an 
incremental update file ." (emphasis added) where 'out of synchronization' in conjunction with 
'changes...' and 'incremental update...' corresponds to temporally aligned and 'running 
processes' corresponds to the bulk component and bulk processing); and 
• facilitates real-time processing of an account ([0084] "The invention is a Customer Care and 
Billing (CCB) solution, providing convergent and modular functionality, real-time information , 
drastically shortened time to market, and a flexible architecture."). 
Hanagan does not specifically teach the notion of a catch-up component, per se, but Pather in an 
analogous art pertaining to programming models for subscription services, does. In at least col. 28, 
lines 59-62 ([28,59-62]) "Additionally, developers may specify the number of quan-tums that the 
logical generator clock can fall behind the real time clock before processing of subscription rules (both 
event and scheduled) is skipped in order to catch up .") 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the modular system models, components and methods of Hanagan that batch 
process subscription and billing accounts with the methods of Pather that provide a mechanism for 
'catching up' because account processing data handled in batches is highly scalable and thus 
merging corrected data, as by the error component, is important so that all accounts can be handled, 
but the error correction processing may cause many accounts to "fall behind" (Pather [28,51]) the 
appropriate processing time frame, hence, the capability to catch up avoids this problem by 
maintaining the timeliness of the data processing. 
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Claims 2 and 16: 

Hanagan teaches the following limitation: 

• the tasks are processed sequentially (see [0157] and [0259] "The sequence of calculations...") 
against the plurality of eligible accounts ([0180] "Maintain Customer Accounts") according to task 
dependencies ([0329]). 

Claims 3 and 17: 

Hanagan teaches the following limitation: 

• the bulk component repeatedly processes the errored account a predetermined number of 
attempts before the errored account is removed by the removal component for error processing 
([0247] "A raw event record file is rejected if it contains too many erroneous records (where "too 
many" is specified in a user-defined parameter )..." and in [0283] "the cycle can be approved for 
distribution or rejected to be reprocessed ." (emphasis added) and finally, in [0250] see "error 
correction" and [0476] for "deletions" and removal component)). 

Claims 4 and 23: 

Hanagan teaches the following limitation: 

• merging the errored account ([0250] "Single erroneous UE records are errored out and written to 
an Invalid Event Records File.") that has been resolved with the one or more eligible accounts for 
further processing in bulk ([0250] "A GUI is also provided for error correction . [...] The validated 
UE records are written to files (different files (same format) for assembly and non-assembly 
records)." (emphasis added) where 'validated' corresponds to errored account that has been 
resolved and 'assembly' corresponds to merging... see also [0477] "The framework merges 
master and incremental update files..."). 

Claim 5: 

Hanagan teaches the following limitation: 

• the errored account is merged back in only when the errored account has been resolved (see the 
rejections of claims 4 and 23 above. Note the phrase therein that has been resolved... is logically 
equivalent to the condition/limitation only when the...) temporally with processing of the bulk 
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component ([0476] "Over time the master file will get out of synchronization with the database 
because of database inserts, updates or deletions that are applied to the database table. For 
large tables supporting time critical functionality, these additional changes are captured 
periodically and made available to running processes in an incremental update file ." (emphasis 
added) where 'out of synchronization' in conjunction with 'changes...' and 'incremental update...' 
corresponds to resolved temporally and 'running processes' corresponds to the bulk component). 
Claim 8: 

Hanagan teaches the following limitation: 

• the dependent tasks processed on a first day must be processed error-free before the same tasks 
can be processed on a succeeding day ([0082]: "The result is a workflow, identifying the proper 
order in which tasks must be completed , the estimated time required to perform a task, and the 
type of resource(s) required for each task. OP 22 actively monitors each task, generating alarms 
for potential error conditions , such as tasks failing to start or finish at their scheduled time. OP 22 
completely automates order scheduling and processing. This eliminates time-consuming errors 
due to missed steps and improper work implementations , freeing valuable resources to perform 
other value." (emphasis added)). 

Claim 9: 

Hanagan does not specifically teach the following limitation, but Pather, in an analogous art pertaining 
to programming models for subscription services, does as shown. 

• comprising a catch-up component for real-time processing of an account (In at least col. 28, lines 
59-62 ([28,59-62]) "Additionally, developers may specify the number of quan-tums that the logical 
generator clock can fall behind the real time clock before processing of subscription rules (both 
event and scheduled) is skipped in order to catch up .") 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the modular system models, components and methods of Hanagan that batch 
process subscription and billing accounts with the methods of Pather that provide a mechanism for 
'catching up' because account processing data handled in batches is highly scalable and thus 
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merging corrected data, as by the error component, is important so that all accounts can be handled, 
but the error correction processing may cause many accounts to "fall behind" (Pather [28,51]) the 
appropriate processing time frame, hence, the capability to catch up avoids this problem by 
maintaining the timeliness of the data processing. 
Claims 10 and 19: 

Hanagan teaches the following limitation: 

• the bulk component ([0357] "batch environment") is associated with periodic processing ([0306] 
"on a periodic basis") of the plurality of eligible ([0411] "row is valid" and in [0078] "providing 
advanced features to additionally support scripting and validations ." (emphasis added)) 
(subscriber) accounts ([0102] "customer subscription information"). 

Claim 11: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in parallel by one or more computing devices 
([0268] "ERP [ ] is designed for parallel processing and the workload is balanced between the 
different processes by workload servers ."). 

Claim 12: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in parallel by different threads of execution on a 
single computing device ([0396] "On-line application servers are multi-threaded."). 

Claim 13: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in accordance with an access control list ([0456] 
regarding data security and "login screens". Also, in [0432] "restrict unauthorized access"). 

Hanagan does not specifically refer to an access control list per se, but Examiner takes Official Notice 
that it is old and well-known as well as common place in the information processing arts to restrict 
access to computer services and information using various standard mechanisms, among these is 
the use of access control lists of authorized users. Therefore, it would have been obvious to one of 
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ordinary skill in the art at the time the invention was made to incorporate an access control list and 
process accounts in accordance therewith because preserving data security and integrity is a 
necessary condition for ensuring the utility and the functionality of any large-scale information 
processing system and the utility of such restrictions were predictable at the time of the invention. 
Claim 14: 

Hanagan does not specifically teach the following limitation, but Pather, as shown, does: 
• wherein the system is restrained to keep system resources ([23, 23]: "Such a factor can be 
considered a trade-off between improving application speed and monopolizing system 
resources." and corresponds to the effect of self-throttling. In addition, Pather repeatedly refers 
to "a predetermined threshold" (see e.g., [77,23]) under a predetermined threshold ([24,1]: "A 
value specified for distributor settings should also be considered in terms of a trade-off between 
improving application speed and monopolizing system resources." (emphasis added) where 'a 
value specified' corresponds to a predetermined threshold.) if the number of dependencies 
associated with an account are below a second threshold, the predetermined threshold defining a 
limit on the use of system resources (Pather [17,64] states "Second, an application does not have 
unlimited time and resources.", and in Pather [24,1] refers to a threshold that provides a limit on 
use of system resources: "A value specified for distributor settings should also be considered in 
terms of a trade-off between improving application speed and monopolizing system resources.", 
and in Pather [23,55]: " By lowering the thread pool size , generator processing speed will 
decrease, but the generator's demand for system resources will also decrease ." (emphasis 
added) where the emphasized text indicates a threshold that provides a limit to the 'demand for 
system resources'.). 

Neither Hanagan nor Pather specifically teach that the number of task dependencies corresponds to a 
predetermined threshold, but Examiner takes Official Notice that it is old and well-known as well as 
common place account processing arts that the number of task dependencies can serve as a threshold or 
limiting value on the utilization of system resources. Hanagan [0329] indicates such relationships to wit: 
"Advanced Scheduling Algorithms — [ ] supports all types of standard scheduling algorithms. Task 
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dependencies , service request dependencies , and resource availability are all taken into account during 
the scheduling process." (emphasis added) and in Hanagan [0082]: "The work request is analyzed to 
determine the tasks required to complete the request , as well as all scheduling dependencies that are 
required. The result is a workflow, identifying the proper order in which tasks must be completed, the 
estimated time required to perform a task, and the type of resource(s) required for each task. [...] actively 
monitors each task, generating alarms for potential error conditions, such as tasks failing to start or finish 
at their scheduled time. [...] completely automates order scheduling and processing. This eliminates 
time-consuming errors due to missed steps and improper work implementations, freeing valuable 
resources to perform other value added functions." (emphasis added). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention to combine the teachings of Hanagan 
and Pather and what is old and well-known to use the aforementioned threshold and to self-throttle 
because it provides a mechanism whereby system administrators can effect a tradeoff between speed 
and system resources as noted above and that the benefits of this capability were known at the time of 
the invention and were predictable. 
Claim 20: 

Hanagan teaches the following limitation: 

• the bulk component fetches only the required number of accounts for processing based on the 
set of tasks to be processed ([0415]: "The parts of the invention that operate without direct user 
interaction are called "batch" and "stream I/O". Batch units of workload are initiated periodically, 
usually according to a pre-defined time schedule or by predictable arrival of an occasional event 
or file of events from an external system ." (emphasis added) and in [0416]: " Each batch process 
inherits from the HvfApplication infrastructure class, which provides a context for handling event- 
based processing . [...] This is accomplished by coding a method Process Message that provides 
application-specific handling of asynchronous input queue messages." (emphasis added) where 
the emphasized text indicates an association between various batch (bulk) processes and a 
particular sef of tasks.) 
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Claim 21: 

Hanagan teaches the following limitation: 

• the bulk component and the error component process accounts concurrently ([0443]: "Error 
Handling: Error handling allows applications to deal consistently with error or fault situations. 
Error handling for batch applications is different in some respects than for on-line applications 
since high-volume errors must not stop processing as long as work can continue. On-line errors 
generally must be dealt with immediately ." (emphasis added)). 

Claim 24: 

Hanagan teaches the following limitation: 

• the processing in bulk further comprises, 

• processing task dependency data related to the set of tasks ([0329]: " Task dependencies , 
service reguest dependencies, and resource availability are all taken into account during the 
scheduling process."); 

• maintaining system state data of the system (see [0316] regarding "State Transition 
Knowledge Base"); 

• generating an account level exception list of exceptions generated during 
the processing in bulk (In at least [0162] reference is made to "processing" and "exception 
logic". Further, in [0247] "...the Error Report File..." which is eguivalent to an account level 
exception list. Also, in [0443] "Error handling for batch applications..." where this also 
pertains to accounts] as shown in [0081] "The Customer Bill Manager... the mass batch of 
documents."); 

• monitoring and reporting system processes related to at least bulk processing ([0330]: "The 
invention monitors tasks for these conditions and creates alarms that are directed to workers 
to inform them of the problems." (emphasis added)), 

• removing an errored account ([0252] "Filters can be set up to filter out records. [...]" and in 
[0250] "Single erroneous UE records are errored out [...]"); and 

• providing error handling related to an error generated by the errored account ([0443]). 
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Claim 25: 

Hanagan teaches the following limitation: 

• reprocessing the errored account in bulk before removing the account for error processing 
(see the rejections of claims 3 and 17). 

Claim 26: 

Hanagan does not specifically teach the limitation reprocessing the errored account before requiring 
manual intervention to initiate further reprocessing, but Examiner takes Official Notice that it is old 
and well-known as well as common place in the workflow processing arts to initiate repeated attempts 
to process a specific task before requiring manual intervention as this increases the likelihood of 
enabling "customer service representatives [to] spend more time focusing on the customer and less 
time on manual and redundant tasks." Hanagan [0078]. Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to include the steps of reprocessing 
attempt to mitigate the necessity of manual intervention because this can tend to increase system 
productivity (see e.g., [0328]). 
Claim 27: 

Hanagan teaches the following limitation: 

• predicting when subscription cycle end processing needs to be performed next (See the 
rejection of claim 18 above and [0307]. Also, in [0082]: "OP 22 completely automates order 
scheduling and processing." and in [0415]: "Batch units of workload are initiated periodically , 
usually according to a pre-defined time schedule or by predictable arrival of an occasional 
event or file of events from an external system." (emphasis added) where 'workload...' 
corresponds to subscription cycle end process as in the rejection of claim 18, 'pre-defined...' 
and 'predictable...' and '...event' corresponds to the limitation since scheduling an event or 
task is equivalent to predicting when...). 
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Claim 29: 

Hanagan teaches the following limitation: 

• determining according to a predetermined threshold level when a second account that is 
dependent on a first account is considered inconsistent (Regarding the first and second account 
(dependent on...) in in [0133] "These types of customers are generally large with multiple 
invoices, accounts, and locations." (emphasis added) hence related or dependent accounts. In 
[0250-3]: "The Validator [ ] validates the [ ] records for correctness and [...] performs different 
types of edits on the fields of the internal record format (for example, numeric checks, date 
validations, and value checks). Moreover, the Validator determines which records need to be 
assembled for long duration. An event record file is rejected if it contains too many erroneous 
records (as specified in a parameter ). [...] Several error groups can be defined. [...] The 
importance of the error group determines how to handle the record (for example, ignore the 
incorrectness, recycle the record, or write it to the Invalid Event Records File). The error severity 
can be configured . [...] Corrections can be applied either to individual records, or to multiple 
records grouped by error codes and error groups. [...] A warning is issued when configurable 
specified thresholds are passed .") 
Claim 32: 

Hanagan teaches the following limitation: 

• a first system that processes a set of tasks against a plurality of accounts; 

• a second system that processes the same set of tasks against the plurality of accounts 
periodically (Hanagan [0415] states " Batch units of workload are initiated periodically , usually 
according to a pre-defined time schedule or by predictable arrival of an occasional event or 
file of events from an external system." (emphasis added).) wherein the first system signals 
the second system to bypass processing of one of the plurality of accounts if the first system 
determines an error in the one account ([0163]: "Even when alternative processing is used , 
the event continues along the common path once the exception logic is completed ." In 
[0444]: "This service allows processes to be controlled by a central control and management 
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process (C&M). In this case, C&M can start, stop (gracefully or immediately) and monitor 
processes to verify their current state (running or in error )." (emphasis added) where 
'processes' refers to at least two system elements or systems. In [0250]: "The Validator 176 
validates the UE (Unrated Event) records for correctness and sends the UE records to the 
Duplicate Event Check process . [...] An event record file is rejected if it contains too many 
erroneous records (as specified in a parameter). Single erroneous UE records are errored out 
and written to an Invalid Event Records File. [...] The importance of the error group 
determines how to handle the record (for example, ignore the incorrectness, recycle the 
record, or write it to the Invalid Event Records File )" (emphasis added) where 'write it to 
the...' corresponds to bypass processing. Also, in [0475]: " Multiple processes can share 
memory-mapped files. If two processes on the same machine map to the same file , the file 
will be loaded into memory only once." (emphasis added) where 'file' corresponds to 
accounts and 'multiple processes' corresponds to processes a set of tasks...). 

Claim 33: 

Hanagan teaches the following limitation: 

• the second system signals the first system to bypass processing of another of the plurality of 
accounts if the second system determines an error in the another account (In [0445]: "Using 
special workload balancing processes, message queuing provides a straightforward 
mechanism for load balancing across multiple batch application processes serving the same 
function ." (emphasis added) and see the rejection of claim 32 above.). 

17. Claim 34 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hanagan, et al. (US 
PgPub 20040133487 A1) in view of Pather, ef al. (US 7177859 B2) and further in view of 
Seshadri, ef al. (US PgPub 20040002988 A1). 
Claim 34: 

Hanagan teaches the following limitation: 

• a bulk component ([0357] "batch environment") that concurrently processes ([0357] 
"automatically processed in parallel") a plurality of eligible accounts ([041 1] "row is valid" and 
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in [0078] "providing advanced features to additionally support scripting and validations ." 
(emphasis added)) with a set of dependent tasks periodically ([0329] "Task dependencies". 
Hanagan [0415] states " Batch units of workload are initiated periodically , usually according to 
a pre-defined time schedule or by predictable arrival of an occasional event or file of events 
from an external system." (emphasis added).); 

• a removal component (Abstract: "The components are modular." and in [0252] "Filters can be 
set up to filter out records. [...] Filters are defined using the ERP graphical user interface ." 
(emphasis added) where 'filter out' corresponds to removal and 'ERP...' corresponds to 
component) that removes an account from the eligible accounts as an errored account if an 
error is associated therewith ([0250] "Single erroneous UE records are errored out and 
written to an Invalid Event Records File. If some records are rejected due to invalid field 
contents, the reason is written to an Error File." (emphasis added) where 'records' 
corresponds to eligible accounts and 'errored out' corresponds to an errored account); 

• an error component ([0149-56] "...in the case an error is detected." See also [0250] "The 
Validator") that processes the errored account ([0250] "Single erroneous UE records are 
errored out and written to an Invalid Event Records File.") to resolve the error associated 
therewith (see [0250] and [0443] "Error Handling"), and merges the resolved errored account 
with bulk processing ([0250] "A GUI is also provided for error correction . [...] The validated 
UE records are written to files (different files (same format) for assembly and non-assembly 
records)." (emphasis added) where 'validated' corresponds to resolved errored account and 
'assembly' corresponds to merges... see also [0477] "The framework merges master and 
incremental update files...") of the eligible accounts by the bulk component when the 
resolved errored account is temporally aligned with the bulk processing ([0476] "Over time 
the master file will get out of synchronization with the database because of database inserts, 
updates or deletions that are applied to the database table. For large tables supporting time 
critical functionality, these additional changes are captured periodically and made available to 
running processes in an incremental update file ." (emphasis added) where 'out of 
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synchronization' in conjunction with 'changes...' and 'incremental update...' corresponds to 
temporally aligned and 'running processes' corresponds to the bulk component and bulk 
processing); and 

Hanagan does not specifically teach the notion of a catch-up component that facilitates real-time 
processing of an account, per se, but Pather in an analogous art pertaining to programming models 
for subscription services, does. In at least col. 28, lines 59-62 ([28,59-62]) "Additionally, developers 
may specify the number of quantums that the logical generator clock can fall behind the real time 
clock before processing of subscription rules (both event and scheduled) is skipped in order to catch 
up.."). Neither Hanagan nor Pather specifically teach that the bulk component processes the errored 
account with a predetermined threshold number of attempts to resolve the errored account so that the 
account state is in par with the rest of accounts being processed by bulk mode, but Seshadri, in an 
analogous art does. Seshadri [0099] states: "With respect to the distributor, it should be noted that 
retry functionality can be provided wherein the platform allows application developers to specify a 
pattern of retry attempts for failed notifications and retrys are implemented accordingly without 
requiring an application developer to specificy an inordinate amount of extra logic." (emphasis added) 
and in [0338] and [0344] describes a "retry schedule" and in [0345] describes an "element [that] can 
be used to define the number of failures that may occur before a system event log entry is created to 
document the failure." (emphasis added) where the emphasized text corresponds to a predetermined 
threshold number of attempts to resolve the errored account. Note that Seshadri also teaches batch 
processing in at least [0126] and in many other paragraphs. Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to combine the teaching of Hanagan 
and Pather with Seshadri because the bulk (batch) processing capabilities taught in Seshadri 
increases the efficiency (Seshadri [0007]) of the account processing system and the technical 
capability to combine these teaching existed at the time of the invention and the result was 
predictable. 
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The prior art made of record and not relied upon that is considered pertinent to applicant's 
disclosure are: 

• Seshadri, et al. (US PgPub 20040002988 A1) 

• Savage, et al. (US 7236950 B2) and pertain to account processing. 

Any inquiry of a general nature or relating to the status of this application or concerning this 
communication or earlier communications from the Examiner should be directed to Mark A. Fleischer 
whose telephone number is 571.270.3925. The Examiner can normally be reached on Monday-Friday, 
9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner's 
supervisor, Bradley Bayat whose telephone number is 571.272.6704 may be contacted. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see 

http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov >. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll- 
free). 
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Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 

P.O. Box 1450 
Alexandria, VA 22313-1450 

or faxed to 571-273-8300. 

Hand delivered responses should be brought to the United States Patent and Trademark Office 
Customer Service Window: 

Randolph Building 
401 Dulany Street 
Alexandria, VA 22314. 

Mark A. Fleischer 
/Mark A Fleischer/ 
Examiner, Art Unit 3624 29 September 2008 
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Supervisory Patent Examiner, Art Unit 3624 



